Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Document iteration order of retain functions #86790

Merged
merged 1 commit into from
Jul 23, 2021
Merged

Document iteration order of retain functions #86790

merged 1 commit into from
Jul 23, 2021
+4 −0

Conversation

janikrabe
Copy link
Contributor

For HashSet and HashMap, this simply copies the comment from
BinaryHeap::retain.

For BTreeSet and BTreeMap, this adds an additional guarantee that
wasn't previously documented. I think that because these data structures
are inherently ordered and other functions guarantee ordered iteration,
it makes sense to provide this guarantee for retain as well.

@janikrabe
Document iteration order of retain functions
2dd69aa 
For `HashSet` and `HashMap`, this simply copies the comment from
`BinaryHeap::retain`.

For `BTreeSet` and `BTreeMap`, this adds an additional guarantee that
wasn't previously documented. I think that because these data structures
are inherently ordered and other functions guarantee ordered iteration,
it makes sense to provide this guarantee for `retain` as well.
@janikrabe janikrabe mentioned this pull request Jul 1, 2021
Merged
@janikrabe
Copy link
Contributor Author

r? @kennytm

Assigning this to you because you're assigned the related #86789.

@janikrabe
Copy link
Contributor Author

@rustbot label: +S-waiting-on-review

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 1, 2021
@the8472
Copy link
Member

the8472 commented Jul 1, 2021

Are there any theoretical optimizations that would be precluded by guaranteeing a specific order?

@cuviper
Copy link
Member

cuviper commented Jul 1, 2021

BTree could visit in pre- or post-order, but I don't know if that would have any real advantages.

@janikrabe
Copy link
Contributor Author

janikrabe commented Jul 2, 2021 •
edited
Loading

Maybe someone more familiar with B-trees could comment on this, but for arbitrary closures I don't believe retain can be optimized significantly by changing the iteration order (perhaps slightly by reducing the number of rotations?) If it can, it may also be worth reconsidering the guarantees of the (still unstable) drain_filter functions the current implementation of retain uses, although in my opinion it makes sense to always guarantee ordered iteration for BTreeSet and BTreeMap regardless (as I think that's how people expect these data structures to work.)

@m-ou-se m-ou-se added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jul 5, 2021
@m-ou-se m-ou-se assigned m-ou-se and unassigned kennytm Jul 5, 2021
@m-ou-se
Copy link
Member

m-ou-se commented Jul 5, 2021

This promises .retain() on BTreeMap and BTreeSet visits the elements in order, as they already do right now.

My thoughts: I can imagine there might be some more efficient implementation that calls the predicate in a different order based on the structure of the tree, but there are probably already people depending on the order of .retain(), since we have the same promise for some other data structures. If we find out about an optimized version that does not call the predicate in order, we can consider adding a retain_unordered if the difference is significant. But for retain, it'd be good to promise the current behaviour as stable, since that's most likely what many users already expect and assume.

@rfcbot merge

@rfcbot
Copy link

rfcbot commented Jul 5, 2021 •
edited by yaahc
Loading

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Jul 5, 2021
@rfcbot
Copy link

rfcbot commented Jul 7, 2021

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Jul 17, 2021
@rfcbot
Copy link

rfcbot commented Jul 17, 2021

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

@rfcbot rfcbot added the to-announce Announce this issue on triage meeting label Jul 17, 2021
@kennytm
Copy link
Member

kennytm commented Jul 23, 2021

why is this still open 🙃

@bors r=m-ou-se rollup

@bors
Copy link
Contributor

bors commented Jul 23, 2021

📌 Commit 2dd69aa has been approved by m-ou-se

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 23, 2021
@JohnTitor JohnTitor mentioned this pull request Jul 23, 2021
Merged
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 23, 2021
@bors
Auto merge of rust-lang#87413 - JohnTitor:rollup-dht22jk, r=JohnTitor
67b0300 
Rollup of 14 pull requests

Successful merges:

 - rust-lang#86410 (VecMap::get_value_matching should return just one element)
 - rust-lang#86790 (Document iteration order of `retain` functions)
 - rust-lang#87171 (Remove Option from BufWriter)
 - rust-lang#87175 (Stabilize `into_parts()` and `into_error()`)
 - rust-lang#87185 (Fix panics on Windows when the build was cancelled)
 - rust-lang#87191 (Package LLVM libs for the target rather than the build host)
 - rust-lang#87255 (better support for running libcore tests with Miri)
 - rust-lang#87266 (Add testcase for 87076)
 - rust-lang#87283 (Add `--codegen-backends=foo,bar` configure flag)
 - rust-lang#87322 (fix: clarify suggestion that `&T` must refer to `T: Sync` for `&T: Send`)
 - rust-lang#87358 (Fix `--dry-run` when download-ci-llvm is set)
 - rust-lang#87380 (Don't default to `submodules = true` unless the rust repo has a .git directory)
 - rust-lang#87398 (Add test for fonts used for module items)
 - rust-lang#87412 (Add missing article)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 249a11f into rust-lang:master Jul 23, 2021
@rustbot rustbot added this to the 1.55.0 milestone Jul 23, 2021
@apiraino
Copy link
Contributor

apiraino commented Aug 5, 2021

@rustbot label -to-announce

@rustbot rustbot removed the to-announce Announce this issue on triage meeting label Aug 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@m-ou-se m-ou-se

Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.55.0
Development

Successfully merging this pull request may close these issues.
9 participants
@janikrabe @the8472 @cuviper @m-ou-se @rfcbot @kennytm @bors @apiraino @rustbot